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A LETTER TO ALL TIP USERS 
Dear TIP Users, 


You will shortly be sent a revised version of the "TIP User’s 


Guide." Besides now having a loose leaf format, mainly descriptions 
of new commands have been added. Appendix B will be an alphabetical 
list of all TIP commands. The new commands are: 


@BINARY INPUT START 
@BINARY INPUT END 
@BINARY OUTPUT START 
@BINARY OUTPUT END 
@CLEAR DEVICE WILD 
@CLEAR INSERT LINEFEED 
@INSERT LINEFEED 
@SEND COMMAND 
@RECEIVE FROM WILD 
@SEND TO WILD 

@SET DEVICE WILD 
@MAG ABORT 

BACKSPACE FILE 
BACKSPACE RECORD 
READ FILE 

READ RECORD 
SETUP COPY 
SPACE FILE 
SPACE RECORD 
UNLOAD 

WRITE EOF 

WRITE TAPE 


The MAG commands are, of course, not relevant to users of TIPs without 
the magnetic tape option. 


A TIP system including the above commands has been in operation 


since late June. We think this system is a substantial improvement 
over previous versions. 
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In case you’ve not been keeping track, there are now eleven TIPs 
in the ARPA Network. These are ETAC, GWC, AMES, ARPA, MITRE, NBS, 
BBN, USC, NOAA, ROME, and SAAC. Also, a TIP will soon be installed at 
CCA. 


I’ll now briefly discuss a number of topics I think may be 
interesting to you. 


Getting TIP status information. As we develop new features for 
the TIP and fix bugs, we are continually releasing new versions of the 
TIP program. We do this by just reloading your TIP when you’re not 
looking (i.e., when no one is using your TIP). In the future we will 
notify you whenever a new version of the TIP program is loaded into 
your TIP by adding a tiny "Status message" to the "HELLO" you get when 
you "log onto" the TIP. This status message will usually be merely 
the TIP’s version number; however, occasionally the message will 
indicate (by typing "NEWS") that there is some news about the TIP’s 
status which you should read before continuing your session with the 
TIP. The NEWS can be retrieved by typing the command @NEWS which will 
ICP to a special socket at BBN’s TENEX or PDP-1D which will print the 
news. Of course, either of these systems may sometimes be down, but 
we won’t worry about the problem until we see how serious it is. 


To whom to complain or make suggestions. Many of you have had 
occasion to complain about the operation of your TIP system or to make 
suggestions for its improvement. All too frequently, however, these 
complaints have been directed to the Host system you are using from 
the TIP instead of to us. BBN maintains a Network Control Center 
which is always manned. Its telephone number is 617-661-0100. All 
TIP problems should be reported immediately to the Network Control 
Center. If you have a suggestion for a new command, or if you think 
you've found a subtle bug in the TIP program, ask to talk to Dave 
Walden or Bernie Cosell when you call the Network Control Center. 


Device buffers. In general, each TIP MLC port has a different 
size buffer allocated to it and therefore to the device connected to 
the port. Devices which operate at higher speeds, of course, require 
larger buffers, especially output buffers. If you need more buffering 
than you have (frequently indicated by output coming in short bursts), 
try to arrange with whomever is locally responsible for the TIP you’re 
using to come in through a port with a larger buffer allocation. If 
necessary, this person can arrange with us to specially tailor the 
buffer allocation for your TIP. 
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There are presently only about 2500 characters of buffers 
available for the TIPs terminal devices. Since each device has an 
input buffer and two output buffers (output is double buffered), each 
of the 63 devices has available an average of about 13 charac- ters 
for input and 13 characters for each output buffer. Since there is 
continual pressure for new features in the TIP and for old features to 
work more conveniently, the space available for device buffers is 
steadily decreasing. There seem to be two ways to increase the space 
available for device buffers; the first is to get more core memory; 
the second is to modularize the program so that unneeded features can 
be removed from particular sites. For instance, the 2741 code and 
character conversion tables might be removed from a site at which they 
were never used. You always have the option of getting more core for 
your TIP; we are presently working on the latter method and should 
have it ready in a few months. In the mean time, the space available 
for device buffers will probably continue to slowly diminish. 


The nominal (untailored) buffer sizes are presently about as 
follows: 


device input (characters) output (characters/buffer) 
L=3 60 56 

4-7 28 27 
8-15 20 20 

16-32 12 13 

33-63 6 6 


Echoing. The TIP’s echoing capability has been a controversial 
item in the past. We have recently fixed it up a little and we think 
that if you try it now, you'll like it a lot better. Unfortunately, 
"@@" is still not echoed correctly very often; this is a bug and we 
are going to fix it, but it’s hairy to fix. 


We will shortly be removing three of the ECHO commands (ECHO ALL, 
ECHO HALFDUPLEX, and ECHO NONE) and be slightly changing the meaning 
of the two other ECHO commands (ECHO REMOTE and ECHO LOCAL). We will 
also add two new ECHO commands (PHYSICAL HALFDUPLEX and PHYSICAL 
FULLDUPLEX.) Thus the new set of ECHO commands will be: 


@PHYSICAL HALFDUPLEX 
@PHYSICAL FULLDUPLEX 
@ECHO LOCAL 
@ECHO REMOTE 
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The ECHO LOCAL and ECHO REMOTE commands will probably be ignored for 
physical halfduplex devices. Therefore, for physical full- duplex 
devices, ECHO LOCAL and ECHO REMOTE will have the effect of declaring 
the device to be virtual halfduplex or virtual full- duplex. Devices 
which are known to be physical halfduplex (e.g., IBM 2741's) will come 
up in physical halfduplex mode. All other devices will come up in 
physical fullduplex mode and local echo mode (i.e., virtual halfduplex 
mode). Whenever a connection is opened, the TIP will automatically 
send off the current virtual echo mode to the server. Whenever a ECHO 
LOCAL or ECHO REMOTE command is given, the virtual mode will be 
appropriately updated and forwarded to the server. When the Telnet 
ECHO (code 132) (=virtual fullduplex) or Telnet NO ECHO (code 131) 
(=virtual half- duplex) characters are received by the TIP, it will 
follow the following rules: 


ECHO received and 


TIP is physical halfduplex -- NO ECHO sent to server 

TIP is virtual halfduplex -- ECHO sent to server and 
mode changed to virtual 
fullduplex 

TIP is virtual fullduplex -- nothing 


NO ECHO received and 


TIP is physical halfduplex -- nothing 

TIP is virtual halfduplex -- nothing 

TIP is virtual fullduplex -- NO ECHO sent to server and 
mode changed to virtual 
halfduplex 


When a connection is broken, devices in physical fullduplex mode will 
be reset to virtual halfduplex mode. 


Some other command changes we are planning to make. 


1. PROTOCOL TO LOGIN will be removed. It has been replaced by 
LOGIN. 

2. LOGIN will take a parameter, the Host number, so it will not 
be necessary to give both HOST and LOGIN commands. 


Some things which we are presently doing. 
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1. When a terminal hangs up, any captured devices will be given 
back. 

2. Output to high speed devices will be possible. 

3. Data sets will automatically be hung up when the caller 


disconnects even though the caller never "logged in". 

202C modems will work. 

Major improvements on the magnetic tape option. 

Trying to find the "R half" of the "R T CLOSED" message. 

We have received numerous complaints that the TIP once ina 
while loses an allocate. We will fix this or else demonstrate 
it’s not the TIP’s fault. 


YOO SS 


Some things we are thinking about. 


1. Adding a lower case capability for Model 33 Teletypes. 
2. Adding a mechanism so the TIP’s status or a device’s status 
(e.g., its device number) can be obtained by the user. 


Each of the above mentioned changes will be preceded by 
notification via the NEWS and we plan to issue frequent updates to the 
TIP User’s Guide from now on. 

We are trying hard to improve the TIP. If you’ve got a 
suggestion (especially if it doesn’t take any memory), let me hear 
from you. 

Regards, 


< signed "Dave" > 


David C. Walden 
Bolt Beranek and Newman Inc. 


July 11, 1972 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by BBN Corp. under the ] 
[ direction of Alex McKenzie. 1/97 ] 
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